QRZ! Ham Radio 4/QRZ Ham Radio Callsign Database - Volume 4.iso/digests/tcp/940024.txt

Internet Message Format | 1994-11-13 | 6KB

Date: Thu, 27 Jan 94 04:30:01 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V94 #24
To: tcp-group-digest


TCP-Group Digest            Thu, 27 Jan 94       Volume 94 : Issue   24

Today's Topics:
                         Ethernet protocol ID
                TCP MSS and TCP WIN settings (2 msgs)

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Wed, 26 Jan 94 10:44:14 PST
From: [e-mail] (Everett F Batey)
Subject: Ethernet protocol ID
To: [e-mail]

Last time I looked there was a complete list of known Vers 2 typefields in
ftp.ftp.com or some such anan ftp server at ftp .. ..  Might do good to post
it here from time to time ..

Also .. If anyone has done any Public Domain work like Sun_s snoop .. similar
in function to Ether Sniff (c?) from Data General or whoevers ether ent tester
I would appreciate a lead to that if it runs on a dos box and runs with winsock.

Welcome and Thanks /Ev .. Wa6Cre/

>
> Does anyone know where I can find a concise (or as consise as possible)
> listing of known ethernet protocol id's??  I know in the ethernetdump
> routing in NOS it identifies 3 of them and then just displays the p

**** FTP Software has this fantastic poster that splits ethernet packets
up into protocol layers and lists all or many of the fields in each layer.
They usually give it out at trade shows, and if you called them and asked
nicely, they just might send you one.

------------------------------

Date: Wed, 26 Jan 1994 10:44:07 -0800
From: Phil Karn <[e-mail]>
Subject: TCP MSS and TCP WIN settings
To: [e-mail]

The MTU Discovery feature allows you to periodically "probe" the path
with a larger packet to see if the minimum MTU has increased since you
last stopped getting ICMP messages.

Of course, it is somewhat problematical to choose the interval at
which you do this probing, because each packet that bounces wastes
bandwidth on the links up to the bounce point.

Phil

------------------------------

Date: Wed, 26 Jan 1994 15:52:58 -0500
From: [e-mail]
Subject: TCP MSS and TCP WIN settings
To: [e-mail]

Phil,

It's hard to determine the real motivations behind a political
situation, but it might be surmountable.  I don't see the exact
problems you see though; things might not be as bad as they look:

>I think there are three problems: one, there was a widespread perception
>that there must exist a way to control gateway congestion without
>having to modify IP and every router that handles it.

True.  You would have to modify all the IPs to at least pass the bit,
if they don't pass it now.  One rule of DECbit is that a router need
not implement it, but must never clear it.

>Two, the
>NSFNet backbone bandwidth has increased almost 1,000x over what it was
back when TCP congestion control algorithms were such a hot topic.
>Despite the enormous growth of the net this has pretty much eliminated
>the widespread backbone congestion that used to occur back then, so
>there is now much less interest in this problem.

Raj describes that as a classical fallacy, albeit one with much
political clout.  You can't solve congestion with bandwidth, just
move it.  Now the backbone is fat but congestion occurs at the low-
bandwidth egress points ("on-ramps").  ATM nets will really see this.

>Three, both TCPs
>in a connection have to be aware of the scheme, because the sending
>TCP relies on the other TCP to "reflect back" the IP congestion
>experienced bit in its own header.

It's simpler than that.  The congestion window is in the receiver,
not the sender.  All you need to do is lower the advertised window
size, not echo back the bit.  That's an advantage of TCP over, say,
HDLC, whose only window is in the sender.  The way we do it is to
make the advertised window the lesser of buffer-space (normal window)
or congestion-allowed window size.  The _loss_ (VJ/CUTE) window in
DECnet/OSI lives in the transmitter, but the _congestion avoidance_
window is the receiver's.  Thus if only one end does it, it can slow
down the ignorant TCP doing the sending.

>I still think it's not too late to install the Decbit scheme in IP.
>There's a spare bit in the flags field (right next to the MF and DF
>bits) that could be used. I've had code in my own IP and TCP for some
>time that reflects this bit back in another spare bit in the TCP
>header, in preparation for eventually implementing the scheme. Again,
>I wanted to make sure that there would be enough compatible systems
>out there to make this thing work. But I haven't taken it beyond that.

That spare bit just sort of begs to be used for this, doesn't it?
I think somebody once suggested it at IETF but got nowhere, but then
I only know that as hearsay and I don't even remember from whom.
    fred   k1io

------------------------------

End of TCP-Group Digest V94 #24
******************************